home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group95a.txt
/
000047_icon-group-sender _Sun Feb 5 03:11:48 1995.msg
< prev
next >
Wrap
Internet Message Format
|
1995-02-09
|
2KB
Received: by cheltenham.cs.arizona.edu; Sun, 5 Feb 1995 02:11:58 MST
Date: Sun, 5 Feb 1995 03:11:48 -0600
From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery)
Message-Id: <9502050911.AA29485@runner.utsa.edu>
To: goer@mithra-orinst.uchicago.edu
Cc: icon-group@cs.arizona.edu
In-Reply-To: <9502050752.AA09862@mithra-orinst.uchicago.edu> (goer@mithra-orinst.uchicago.edu)
Subject: Re: sockets for Icon?
Content-Length: 1219
Errors-To: icon-group-errors@cs.arizona.edu
(Richard L. Goerwitz writes:)
Has anyone incorporated any socket code into the Icon run-time system,
or else into any compatible C libraries?
This is asked so often, it needs to go into the FAQ. To my knowledge,
interprocess communication's been done before by numerous people. Brian
Keefe, for example, wrote some simple demo functions for socket access.
I think Gregg Townsend's done an IPC example for the version 9 loadfunc()
facility. IPC is not yet ubiquitous for Icon because language design is
hard when the requirements are simplicity, generality, portability, and
power. Doing It Right will take a lot of effort.
I have a dream of doing interprocess communication "right", which for Icon
means defining a small set of OS-independent, network-independent functions
that seamlessly fit in with the rest of the language. But in order to get
from here to there we have to start with a clean & simple interface and
loadfunc() is the easiest way to prototype it without a lot of run-time
system expertise. I'd be happy to help anyone (or a group) working on a
serious IPC interface; I can advise on run-time system issues and language
design, but my implementation cycles are otherwise committed.